実装してから「なんか違う」を防ぐUIデザインの方法
UIデザインでは、デザイナーが情報設計や見た目の魅力だけしか考慮しないと、実装が完了してから「なんか違う」ものが出来上がったりします。
その理由は「操作が重くて円滑でない」や、「インタラクションがこれじゃない」が多いです。
つまりプロトタイピングツールだけでは検証できない使用感が関与しているからです。
ネイティブ実装でプロトタイプを作る時間があれば良いですが、いつもそうとは限りません。（むしろそうでないことが多いです）
「なんか違う」をあらかじめ回避する方法をいくつか紹介します。
通信速度や読み込みにかかる時間の考慮
例えば、タブバーで画面を切り替えて画面全体が毎回リロードされると、待ち時間でストレスが溜まります。
画面リロードが必須でユースケースや要件で支障が生じる場合は別です。
そうでなければ、この問題を以下の措置で改善が検討できます。
- 一度読み込んだデータはローカルにキャッシュする前提なのかエンジニアに聞く（普通はキャッシュするとは思います）
- 画面全体をリロードしないで、リロードが必要な箇所を局所的にリロードし、操作の遅延をなくせないか
- 必要に応じてユーザーが任意のタイミングでデータをリロードできる仕組みをUIに設ける
デザインフェーズからサーバーやフロントのエンジニアと通信速度や操作パフォーマンスの話をしておきましょう。
インタラクションの選定
シンプルな挙動のインタラクションであっても、それは細かな仕様に支えられているからこそシンプルに使えます。
関係性を無視して安易に扱うと思わぬ壁にぶつかります。
顧客が引き合いに出した優良アプリの局所的なインタラクションを、あなたがデザインしているアプリにそのまま適用できるのでしょうか。
デザイナーがインタラクションを選定する方法には以下のような手段が挙がります。
- インタラクションの仕様を文章と静止画で事細かく指示するドキュメントを作成する
- 関連するOSSをリストアップする
- 可能ならデザイナーがインタラクションをネイティブで実装してモックアップを作る
- 動画オーサリングソフトウェアでアニメーションを作成して伝える
- keynoteのアニメーションで伝える（意外と色々できる）
この中から複数組み合わせると効果的かと思います。
OSのデザインガイドラインに準拠した挙動が実現できるか
「見た目はOSに準拠しているのに、挙動がそれと違う」という現象も起こり得ます。
これは、「何らかの制約で標準コンポーネントを使えなかったが、見た目は少なくとも標準コンポーネントっぽくしました」などの原因に依ることが多いです。
「iOSアプリで、ドリルダウンして進んだページから戻る際に左側画面外からの右スワイプで前のページに戻る」の例のだと、この「右スワイプで戻る」の機能が落ちたりします。
事前にエンジニアと細かく話をしておきましょう。
初回フローの設定
データが０件の際、画面上に「０」が表示されるだけで良いかを検討する必要があります。
初期値０表記だけだと、訳が分からずに離脱するユーザーも出ます。
データ０件の見た目や考えに入れずにダミーデータが十分に入った状態のデザインで進めていると、その画面の理想的なステータスのイメージに支配されがちになります。
ユーザーが０を１〜に増やすには何をすればいいのかを示す導線を設計しておく必要があります。
メインとなる画面に注力しすぎるとこういった機能はMVP（Minimum Viable Product）から落ちガチですが、最初のおもてなしを十分すると後で楽です。
最適なエラー表示
デザイナーとしてはあまり気にしないかもしれませんが、エラーの種類は把握しておいた方が良いです。
- サーバーから返されるエラー
- クライアントでチェックされるエラー
例えば、クライアントでのテキストの入力チェックの際にエラーのアラートが何度も上がってくるUIだとうっとおしくなります。
そういった場合はテキストインプットの近くにそれぞれエラー表記をするのが普通です。
エラーにはどんなものがあるか知り、種類に応じてグルーピングして最適な方法でユーザーをエラーから救済する方法を探りましょう。
